Nautilus 1992 July/Nautilus-3-8/Nautilus-3-8.bin/Tools & Utilities/Techy Stuff/Doco ƒ/CSMP ƒ/CSMP-V1-057.TXT

Text File | 1992-06-03 | 43.2 KB | 1,125 lines

C.S.M.P. Digest             Wed, 22 Apr 92       Volume 1 : Issue 57

Today's Topics:

    need mac program examples
    Prograf visual programming...reactions?
    Accessing specific FCB via FCBSPtr global?
    Experiences with EDUCORP as a Shareware author?
    Contract Job for Mac Programmers
    Converting Existing Mac Header Files to C++
    Porting tcsh to MacOS
    TCL CDialog question
    tickle (was Re: Porting tcsh to MacOS )
    PBOpen crashes on "." names
    Offscreen Bitmap Problem SOLVED!
    Questions on THINK Pascal


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Yary Richard Phillip Hluchan)
Subject: need mac program examples
Date: 10 Mar 92 20:19:23 GMT
Organization: Senior, Electrical and Computer Engineering, Carnegie Mellon, Pittsburgh, PA

I'm trying to use the Macintosh's sound manager as described in Inside Mac
volume 5.  If you have any or know of any archive sites with source code
using this, please tell me... pref. in C... I'm trying to a)have my computer
do some MIDI effects and b)use the midi keyboard to control some simple
8-bit sounds from the computers on-board d/a converter.

I also have a ~7 yr. old A/D converter hooked up to the serial port, current
sound digitizing programs recognize it, any ideas on how to access it? Tomorrow
I'll try hacking with the serl port drivers but I'd rather not drive blind.

Thnak you!  ..yary


+++++++++++++++++++++++++++

From: [e-mail] (Ray Arachelian)
Date: 18 Mar 92 03:29:00 GMT
Organization: FidoNet node 1:2603/204 - Not Even Odd, Forest Hills NY

On 03-10-92, [e-mail] wrote to ALL:

 Y> I also have a ~7 yr. old A/D converter hooked up to the serial port,
 Y> current sound digitizing programs recognize it, any ideas on how to
 Y> access it? Tomorrow I'll try hacking with the serl port drivers but
 Y> I'd rather not drive blind.

I'm almost in the same mess myself.  A long while ago I built a Commodore
128 audio digitizer based on a TI 548(?) chip.  That whole project cost me
$10, who knows, if I can modify it to work on the Mac, I'll upload
instructions on how to build one.  (Granted anything above a IIsi has
built in input, I'm sure there are plenty of us with older machines. :-)

This is a serially interfaced 8 bit A/D chip, and was sold in plenty by
Radio Shack a while back; it worked wonders on the commodore.  However
this chip relied on the clock signals being sent by the CPU over the
serial port to it.  The Mac's SID driver software doesn't do this, so I
have to build some sort of timing device for it, but don't know the
protocol specs for such a device and which pins drive what data over it.

I too would appreciate any info on how the sound input protocol works.

 * Freddie 1.1 * You have been found guilty of commerce with the devil.

- --
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
 Ray Arachelian - Internet: [e-mail]

---------------------------

From: [e-mail] (Jon W. Backstrom)
Subject: Prograf visual programming...reactions?
Organization: University of Illinois at Urbana-Champaign
Date: Tue, 10 Mar 1992 22:26:59 GMT

I've been asked to find out about information "Prograf" from TGS
Systems.  Apparently, this is a visual design tool for software
development that locks you into their own engine for executables.

Has anyone run into any limitations with the system?  (You can add
your own C routines, but I'm worried about being totally locked into
the system without being able to add a necessary routine in the end.)

If you use this tool, please offer me a reaction, positive or
negative...I will summarize to the net.

Thank you!

- -------------------------------------------------------------------------------
 Jon W. Backstrom                   "CD-I Authoring Tools Designed Here"
 User Interface Engineer       OptImage is a Philips and Microware Partnership
 OptImage
 1501 50th Street, Suite 100                    Internet: [e-mail]
 West Des Moines, IA  50265-5961                    UUCP: uunet!optimg!viking
- -------------------------------------------------------------------------------

+++++++++++++++++++++++++++

From: [e-mail] (Jim Coons 5-5092,ct52 )
Organization: GE Medical Systems, Magnetic Resonance
Date: Wed, 11 Mar 92 15:24:31 GMT

>From article <[e-mail]>, by [e-mail] (Jon W. Backstrom):
> I've been asked to find out about information "Prograf" from TGS
> Systems.  Apparently, this is a visual design tool for software
> development that locks you into their own engine for executables.
>
> Has anyone run into any limitations with the system?  (You can add
> your own C routines, but I'm worried about being totally locked into
> the system without being able to add a necessary routine in the end.)
>
> If you use this tool, please offer me a reaction, positive or
> negative...I will summarize to the net.
>
> Thank you!
>
> -------------------------------------------------------------------------------
>  Jon W. Backstrom                   "CD-I Authoring Tools Designed Here"
>  User Interface Engineer       OptImage is a Philips and Microware Partnership
>  OptImage
>  1501 50th Street, Suite 100                    Internet: [e-mail]
>  West Des Moines, IA  50265-5961                    UUCP: uunet!optimg!viking
I have found Prograph to be the easiest, most enjoyable programming
environment that I have ever used.  It is by far the most interactive
environment as well. With the new C, Pascal, and Fortran interface
tools, you can use your existing code as well. It is really the
closest thing to a perfect programming environment that I have seen.

> -------------------------------------------------------------------------------

+++++++++++++++++++++++++++

From: [e-mail] (Patrick Podenski)
Date: 19 Mar 92 16:49:59 GMT
Organization: Boeing Computer Services AI Center, Seattle

The correct spelling is Prograph. It comes from TGS Systems
and their address is:

2745 Dutch Village Road, Suite 200
Halifax, Nova Scotia
Canada  B3L 4G7
[phone]

They will send you a free booklet if you call
[phone]

---------------------------

From: [e-mail] (Eddy J. Gurney)
Subject: Accessing specific FCB via FCBSPtr global?
Date: 11 Mar 92 14:15:15 GMT
Organization: Dept. of Computer Engineering, Michigan State University

OK... I've checked IM and even the UseNet Macintosh Programmer's Guide
Volume I and haven't been able to find a definitive answer to this
question.

The data fork of a file has been opened using a call to _Open.  When
it returns, the ioRefNum (file reference number) from the parameter
block is stored.  So far so good.

I know the FCBSPtr global points to a word which contains the LENGTH
of the FCB buffer, and that following the length word is the start of
the first FCB.

   "100 people surveyed, top three answers on the board - now, here's
   the question:" If a register has the address stored in FCBSPtr and I
   then add to it the file reference number obtained from _Open, where
   will the register be pointing?

If I understand correctly, it should be pointing to the first byte of
the FCB of the file I opened (Is that right so far?)  Do I need to
take into account the length word (i.e., add another 2 bytes) so I can
reference it via the FCBPBRec structure, or is that already taken into
consideration in the file reference number? (again, which I'm assuming
is some sort of an offset into the whole FCB buffer.)

Any info on this would be greatly appreciated!  I know there's probably
another way to do it, but I'm looking for simplicity... you know, ML
and everything...

aTdHvAaNnKcSe,
Eddy

- --
         Eddy J. Gurney  N8FPW       THE ECCENTRICITY GROUP           EEEEGGGG
[e-mail]     [e-mail]     [e-mail]     EEE G GG
   (Preferred)          (If you want to)      (If you HAVE to :-)     EEEEGGGG
- --
   "Failures are divided into two classes-- those who thought and never did,
         and those who did and never thought."     John Charles Salak

+++++++++++++++++++++++++++

From: [e-mail] (Jim Reekes)
Date: 20 Mar 92 20:12:28 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Eddy J. Gurney) writes:
>
> OK... I've checked IM and even the UseNet Macintosh Programmer's Guide
> Volume I and haven't been able to find a definitive answer to this
> question.
>
> The data fork of a file has been opened using a call to _Open.  When
> it returns, the ioRefNum (file reference number) from the parameter
> block is stored.  So far so good.
>
> I know the FCBSPtr global points to a word which contains the LENGTH
> of the FCB buffer, and that following the length word is the start of
> the first FCB.
>
>    "100 people surveyed, top three answers on the board - now, here's
>    the question:" If a register has the address stored in FCBSPtr and I
>    then add to it the file reference number obtained from _Open, where
>    will the register be pointing?
>
> If I understand correctly, it should be pointing to the first byte of
> the FCB of the file I opened (Is that right so far?)  Do I need to
> take into account the length word (i.e., add another 2 bytes) so I can
> reference it via the FCBPBRec structure, or is that already taken into
> consideration in the file reference number? (again, which I'm assuming
> is some sort of an offset into the whole FCB buffer.)
>
> Any info on this would be greatly appreciated!  I know there's probably
> another way to do it, but I'm looking for simplicity... you know, ML
> and everything...

You should be using PBGetFCBInfo, and not accessing the low memory globals.
You can index through them from the first one to the last.  This _is_ the
simplest way, and it's the most compatible method.


- -----------------------------------------------------------------------
Jim Reekes, E.O.             |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | "All opinions expressed are mine, and do
20525 Mariani Ave. MS: 81-KS |   not necessarily represent those of my
Cupertino, CA 95014          |       employer, Apple Computer Inc."

---------------------------

From: [e-mail] (Jonathan Brecher)
Subject: Experiences with EDUCORP as a Shareware author?
Date: 16 Mar 92 10:22:12 GMT
Organization: Harvard Arts and Sciences Computer Services, Cambridge, MA

BACKGROUND:
   A year or two ago I made several Hebrew PostScript fonts (ShalomOldStyle,
ShalomScript, ShalomStick) and distributed them as shareware.  Since every
shareware program I'd ever seen had an anti-EDUCORP clause, I added one as
well, saying that they must contact me for permission to distribute the fonts.
Everything went well.  I even (gasp!) got some payments from happy users.

DILEMMA:
   Now EDUCORP has found my fonts and written me for permission.  I find myself
in a quandry -- I have no idea why I'd possibly want to _deny_ them permission.
I've received lots of advice saying how bad EDUCORP is, but never with
specific details.  So I ask the net:

What do you think of EDUCORP?  Have you liked what they've done for you, or
have they screwed you over?  Why shouldn't I let them distribute my fonts?


SOME RESPONSES SO FAR:
Avoid them -- they're known in some circles as EDUSLIME.
   [no details given]
Best they offered me was the chance to let them distribute my stuff for free
   [ok, but what's wrong with that?  Isn't distribution good?]
See if they'll give you royalties on disks sold
   [anyone done this?]
People will feel they've already paid EDUCORP, so they won't pay you
[yeah, but without EDUCORP they wouldn't have had the font in the first place,
 so they would never have thought of paying before]

Comments?

Email preferred, of course.  I'll summarize if there's interest.

                    jonathan brecher
                    [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (John Nagle)
Date: 17 Mar 92 18:31:13 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)


       The fundamental problem with Educorp is that they publish a catalog
of shareware disks with a price for each disk that doesn't include the
shareware fee.

       Some enterprising person should work out some way to pay for
shareware that looks like a cross between the Copyright Clearance
Center and the automatic registration process for Teleport modems.

                    John Nagle

+++++++++++++++++++++++++++

From: [e-mail] (Matt Mora)
Date: 20 Mar 92 16:20:33 GMT
Organization: SRI International, Menlo Park, California

In article <6=[e-mail]> [e-mail] (John Nagle) writes:

>       Some enterprising person should work out some way to pay for
>shareware that looks like a cross between the Copyright Clearance
>Center and the automatic registration process for Teleport modems.

What Educorp should do is pay a percentage of the shareware fee, kind of
like a royalty payment. Maybe 10% of the shareware cost of the
price of each of the programs on the disk. Then if a user registers
the program the author would give them a 10% discount because the user
has already paid that amount via the cost of the disk.

The disks that Educorp sells are worthless without the programs that are on it.
They should pay somthing to the authors of those programs.

If the programs are freeware then educorp pays nothing.

Matt
- --
___________________________________________________________
Matthew Mora                |   my Mac  [e-mail]
SRI International           |  my unix  [e-mail]
___________________________________________________________

---------------------------

From: [e-mail] (Ramesh Chandak)
Subject: Contract Job for Mac Programmers
Date: 16 Mar 92 21:10:16 GMT
Organization: GTE Laboratories Incorporated, Waltham MA

i have advertised in the relevant newsgroups ( misc.jobs.offered and
misc.jobs.contract ) about a contract opportunity for Mac programmers.

I'd like to know if that could be done here in this forum ? If not, that's
okay.  I thought this could be a good way to reach directly mac programmers
since those other newsgroups reach other audiences as well.

Let me know. Thanx.
- - Ramesh
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Cory Kempf)
Date: Fri, 20 Mar 92 12:22:18 EST
Organization: Howtek, Inc.  Hudson, New Hampshire


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Ramesh Chandak) writes:
>i have advertised in the relevant newsgroups ( misc.jobs.offered and
>misc.jobs.contract ) about a contract opportunity for Mac programmers.
>
>I'd like to know if that could be done here in this forum ? If not, that's
>okay.  I thought this could be a good way to reach directly mac programmers
>since those other newsgroups reach other audiences as well.

Personally, I would rather you didn't.  I think that you will also
find that to be the net.consensus.  If a person who has access to
the net is looking for a job, they will read the jobs newsgroup.
I know I do.  When they are not looking, they frequently unsubscribe.
Putting job postings in their face in other places is rather rude.

+C

- ---------------------------------------------------------------
Cory Kempf                  domain: [e-mail]
Howtek, Inc.            bang: decvax!fasfax!howtek!cory
Remember: Never play russian roulette with a semi-automatic.

---------------------------

From: [e-mail] (Andrew E Page)
Subject: Converting Existing Mac Header Files to C++
Date: 16 Mar 92 22:01:28 GMT
Organization: The World Public Access UNIX, Brookline, MA

/*
In a recent adventure in Mac C++ programming
I was establishing a class that contained
a const Rect member
*/

class ClassWithConstRect {
    const Rect theRect ;
    ClassWithConstRect(int Height, int Width) ;
    } ;

/*
I wanted to have an initializer part of the constructor
that would initialize the const Rect without the need
for a call to some function that would return a Rect.

With some generous advice obtained from the net
(credit to John Hickin for unselfish help)
I tried  the following redefinition of a Rect in
Types.h
*/


#ifndef __cplusplus
struct Rect {
    short top;
    short left;
    short bottom;
    short right;
};
#else
struct Rect {
    short top;
    short left;
    short bottom;
    short right;
        Rect(void) {} ; // Necessary or every Rect in every other structure wants initializers
        Rect(short t, short l, short b, short r)
        : top(t), left(l), bottom(b), right(r) {}
};
#endif

/*
Unfortuantely while the addition of the Rect(void) constructor elimanted most
of the errors caused by the lone Rect(t,l,b,r) constructor it produced the
following error:

File "Andrew:Applications:MPW:Interfaces:CIncludes:Files.h"; line 369 # error:  member CInfoPBRec::dirInfo of class DirInfo with constructor in union

which is essentially griping about the constructor possibly
overwriting in the union where it might not be desired, despite
the fact that the default constructor does not alter any data

*/


/*
Bottom line question:

    Is there some value in what I'm trying above, or should I just
        declare a new 'oRect' structure and cast where I need to in
        order to make it work for anything that I develop?
*/
- --
Andrew E. Page CTO(Warrior Poet)|   Decision and Effort The Archer and Arrow
DSP Ironworks                   |     The difference between what we are
Macintosh and DSP Technology    |           and what we want to be.

+++++++++++++++++++++++++++

From: [e-mail] (Eric Berdahl)
Date: 19 Mar 92 22:33:59 GMT
Organization: Taligent, Inc.

In article <[e-mail]>, [e-mail] (Andrew E Page) writes:
> [Introduction deleted]
> /*
> Bottom line question:
>
>     Is there some value in what I'm trying above, or should I just
>         declare a new 'oRect' structure and cast where I need to in
>         order to make it work for anything that I develop?
> */

Not only is there value in what you're trying to do, it has been done.
In MacApp 3.0, Apple ships a complete set of toolbox #include files that
have been updated for C++-like stuff.  In addition to Rect, which _is_
required to be a dumb struct because of things like unions, there is CRect,
a class that inherits from Rect and adds some cool member functions.  So,
the bottom line is check out MacApp 3.0 and see if it does what you like.

Eric
- --
Eric Berdahl
Internet: [e-mail]
AppleLink: BERDAHL
MaBell: [phone]

+++++++++++++++++++++++++++

From: [e-mail] (Cory Kempf)
Date: Fri, 20 Mar 92 12:32:30 EST
Organization: Howtek, Inc.  Hudson, New Hampshire


In article <[e-mail]> (comp.sys.mac.programmer,comp.lang.c++), [e-mail] (Andrew E Page) writes:
[attempt and reasoning behind a redef. of Rect as a class]

>Bottom line question:

>    Is there some value in what I'm trying above, or should I just
>        declare a new 'oRect' structure and cast where I need to in
>        order to make it work for anything that I develop?

I would suggest that you NOT redefine the type Rect, as there is a
LOT of other code that depends on it working as it always has.  Rather,
create a class 'CRect' or somesuch that does what you want, and provide
constructors/casts for Rects (I would also add a constructor / access
methods that allow access via topLect & botRight).

+C

- ---------------------------------------------------------------
Cory Kempf                  domain: [e-mail]
Howtek, Inc.            bang: decvax!fasfax!howtek!cory
Remember: Never play russian roulette with a semi-automatic.

---------------------------

From: [e-mail] (David G. White)
Subject: Porting tcsh to MacOS
Organization: Computer Services Centre, Australian National University
Date: 18 Mar 92 04:04:42 GMT

I've been wanting for a while to have some sort of CLI on the mac (not because
I prefer CLI's over GUI's or anything-just 'because' ;-) ) and I finally
decided that it would be a better idea to port a unix shell rather than write
one of my own from scratch.  Now I know about that CLIM program but it's a
bit .. unfriendly (and I know that CLI's are unfriendly by default but there
are shades of gray here..) and something like tcsh is much nicer.

My problem is that I don't know C.  However I'm fairly competent in Pascal and
can pick up what I think are the important bits in the distribution files.
(I'm actually tossing up between bash and tcsh).  My other problem stems from
the first in that I only have the PD C compilers to work with (I'm intending
on using Harvest C which is, apparently, MPW compatible).

So basically I'm asking is it worth it or will it take weeks ?  and what will
I have to change in the code to make it run under the MacOS (not A/UX) - in
general ?

Thanks v. much in anticipation.

David.

- --
_ David G. White ________________________   ______   _____ "What I did with _
_ [e-mail] _________________  \    /  ______ Rex Mossop wasnt _
_ 2 Spencer Street, Turner,  ______________  \  /  _______ Porn,it was Art" _
_ ACT 2601, Australia. Ph: [phone] __  \/  ________  - Julian Clarey _

+++++++++++++++++++++++++++

From: [e-mail] (David G. White)
Organization: Australian National University
Date: Wed, 18 Mar 92 04:34:11 GMT

Path: coombs!dave
Date: 18 Mar 92 04:04:42 GMT
Message-ID: <dave.700891482@coombs>
Newsgroups: comp.sys.mac.programmer
Subject: Porting tcsh to MacOS
Keywords: tcsh,compiler

I've been wanting for a while to have some sort of CLI on the mac (not because
I prefer CLI's over GUI's or anything-just 'because' ;-) ) and I finally
decided that it would be a better idea to port a unix shell rather than write
one of my own from scratch.  Now I know about that CLIM program but it's a
bit .. unfriendly (and I know that CLI's are unfriendly by default but there
are shades of gray here..) and something like tcsh is much nicer.

My problem is that I don't know C.  However I'm fairly competent in Pascal and
can pick up what I think are the important bits in the distribution files.
(I'm actually tossing up between bash and tcsh).  My other problem stems from
the first in that I only have the PD C compilers to work with (I'm intending
on using Harvest C which is, apparently, MPW compatible).

So basically I'm asking is it worth it or will it take weeks ?  and what will
I have to change in the code to make it run under the MacOS (not A/UX) - in
general ?

Thanks v. much in anticipation.

David.

- --
_ David G. White ________________________   ______   _____ "What I did with _
_ [e-mail] _________________  \    /  ______ Rex Mossop wasnt _
_ 2 Spencer Street, Turner,  ______________  \  /  _______ Porn,it was Art" _
_ ACT 2601, Australia. Ph: [phone] __  \/  ________  - Julian Clarey _

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Ulrich Neeracher)
Organization: Integrated Systems Laboratory, ETH, Zurich
Date: Wed, 18 Mar 1992 10:49:53 GMT

In article <dave.700891482@coombs> [e-mail] (David G. White) writes:
>I've been wanting for a while to have some sort of CLI on the mac (not because
>I prefer CLI's over GUI's or anything-just 'because' ;-) ) and I finally
>decided that it would be a better idea to port a unix shell rather than write
>one of my own from scratch.  Now I know about that CLIM program but it's a
>bit .. unfriendly (and I know that CLI's are unfriendly by default but there
>are shades of gray here..) and something like tcsh is much nicer.
>
>My problem is that I don't know C.  However I'm fairly competent in Pascal and
>can pick up what I think are the important bits in the distribution files.
>(I'm actually tossing up between bash and tcsh).  My other problem stems from
>the first in that I only have the PD C compilers to work with (I'm intending
>on using Harvest C which is, apparently, MPW compatible).
>
>So basically I'm asking is it worth it or will it take weeks ?  and what will
>I have to change in the code to make it run under the MacOS (not A/UX) - in
>general ?

The problem with shells is that they are just that - shells. But if you wan't
to use them, you have to port at least 50 or so further utilities:

ls
rm
cp
cat

None of which is particularly difficult, but still takes time. Another approach
is to make the shell run MPW tools, not only Applications, but how to catch
standard input/output is completely undocumented.

So: If you have 6 Months time and want to become a top C programmer, by all
means go ahead with your project. But don't expect to do it in 2 weeks.

Matthias

- -----
Matthias Neeracher                                   [e-mail]
   "No, what he didn't like about heroes was that they were usually
    suicidally gloomy when sober and homicidally insane when drunk."
                          -- Terry Pratchett, _The Colour of Magic_

+++++++++++++++++++++++++++

From: [e-mail] (Eric W. Sink)
Organization: University of Illinois at Urbana-Champaign
Date: Wed, 18 Mar 1992 16:01:15 GMT

In <dave.700891482@coombs> [e-mail] (David G. White) writes:

>I've been wanting for a while to have some sort of CLI on the mac (not because
>I prefer CLI's over GUI's or anything-just 'because' ;-) ) and I finally
>decided that it would be a better idea to port a unix shell rather than write
>one of my own from scratch.  Now I know about that CLIM program but it's a
>bit .. unfriendly (and I know that CLI's are unfriendly by default but there
>are shades of gray here..) and something like tcsh is much nicer.

I agree, having tcsh on the Mac would be really nice, but...

>My problem is that I don't know C.  However I'm fairly competent in Pascal and
>can pick up what I think are the important bits in the distribution files.
>(I'm actually tossing up between bash and tcsh).  My other problem stems from
>the first in that I only have the PD C compilers to work with (I'm intending
>on using Harvest C which is, apparently, MPW compatible).

Red alert.  First of all, if you don't know C, this will be a big job.
More precisely, if you were a cyborg combination of Brian Kernighan and
Kent Sandvik, it would still be big job.  Second, a quick scan of the tcsh
source code tells me that you would be dealing with 39540 lines of code,
in 46 C source files plus 23 C header files.  Anything this big is well
beyond the abilities of any version of Harvest C which you have your hands
on.  If you wanted to make a serious stab at the project, you should use
THINK C, but there will still be problems.  Tcsh makes extensive use of
termcap, environment variables, fork/execl, job control, and a number of
other UNIX-dependent things.  All of these are missing in every C development
environment I know of.  In other words, THINK C is a fantastic compiler,
but tcsh is very UNIX dependent.  The task could be done, but it would be
an ENORMOUS job.

Also, as someone else pointed out, just having the shell doesn't mean you
would then have all the utilities that are normally associated with it.
There is darn-little that you can do with tcsh alone.

>So basically I'm asking is it worth it or will it take weeks ?  and what will
>I have to change in the code to make it run under the MacOS (not A/UX) - in
>general ?

Would it be worth it ?  Maybe.
Will it take weeks ?  Longer than that.

If you want to attempt the project, get THINK C.  If I'm going to get email
from Australia, I wouldn't want it to be hostile. :-)  By far the most
stable version of Harvest C is sitting on my Mac right now - nowhere else.
Even that version is just beginning to be able to compile nontrivial Mac
applications.  Compiling anything as big as tcsh while porting it at the
same time would be out of Harvest C's league right now.

OR, wait until the next release of Alpha.  It has a shell built in, and it
is neato.  It's not tcsh, it's based on Tcl, but I like it a lot.

- --
Eric W. Sink,  Spatial Analysis and Systems Team
USACERL, P.O. Box 9005, Champaign, IL 61826-9005
1-800-USA-CERL x449,   [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Ed Lai)
Date: 18 Mar 92 18:46:15 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] writes:
>
>OR, wait until the next release of Alpha.  It has a shell built in, and it
>is neato.  It's not tcsh, it's based on Tcl, but I like it a lot.
>
If you want to have a shell, another program to consider is Tickle, which so
happend is also based on Tcl. You can write XTCL (Tickle's XCMD counterpart)
to extend it to do what you want. XTCL has code resource so you can also do
it with PASCAL. You can get Tickle, which is free by ftp from ftp.msen.com
in the directory pub/vendor/ice.

/* Disclaimer: All statments and opinions expressed are my own */
/* Edmund K. Lai                                               */
/* Apple Computer, MS37-UP                                     */
/* 20525 Mariani Ave,                                          */
/* Cupertino, CA 95014                                         */
/* [phone]                                               */
zW@h9cOi

+++++++++++++++++++++++++++

From: [e-mail] (Cory Kempf)
Date: Fri, 20 Mar 92 00:32:57 EST
Organization: EnigamI, Inc., Nashua, NH


In article <dave.700891482@coombs> (comp.sys.mac.programmer), [e-mail] (David G. White) writes:
>I've been wanting for a while to have some sort of CLI on the mac (not because
>I prefer CLI's over GUI's or anything-just 'because' ;-) ) and I finally
>decided that it would be a better idea to port a unix shell rather than write
>one of my own from scratch.

Real dumb question here, but why not just use the MPW shell?  It is
a command line interface, and it already can control most of the Mac.
 If you added a few additional tools to send some AppleEvents to the
finder or to QuickKeys, I think that you would have what you are looking
for (though why you want it is beyond me!)

+C


- -------------------------------------------------------------
Cory Kempf                    EnigamI, Inc.
[e-mail]           ...!decvax!enigami!cory
Never play Russian Roulette with a semi-automatic.

---------------------------

From: [e-mail]
Subject: TCL CDialog question
Organization: Cornell Information Technologies
Date: Wed, 18 Mar 92 21:04:18 GMT

I'm implementing a dialog box using the CDLOG classes in TCL.  The dialog asks
for user input.  I have an editable DITL where the user types in a name and
then clicks the OK button.  Non-TCL programs can use the GetDItem and GetIText
functions to access what the user typed in.  I'm having a bear of a time trying
to figure out how to get that string from the TCL-created dialog box, because
TCL creates a dialog as panes in a window?

Someone suggested using FindViewByID, but I'm not sure how that's going to
help.

Help.
- ---------------------------------
[e-mail]
Programmer/Analyst
Cornell Information Technologies

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 19 Mar 92 12:15:57 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.cit.cornell.edu> [e-mail] writes:

   Someone suggested using FindViewByID, but I'm not sure how that's going to
   help.

The various item panes gets view ID == DITL number, so if your
edit text item has number 4, do:

    CDialogText * theText = ( CDialogText * ) FindViewByID ( 4 ) ;

    ASSERT ( theText ) ;

    // now get the data out of the text item...


- --
This signature is placed into the Public Domain by Jon W{tte ([e-mail])
                     - The worlds only romantic cynic -

+++++++++++++++++++++++++++

From: [e-mail] (Francois Menneteau)
Date: 20 Mar 92 13:06:32 GMT
Organization: IMAG Institute, University of Grenoble, France

In article <[e-mail]> [e-mail] writes:
>I'm implementing a dialog box using the CDLOG classes in TCL.  The dialog asks
>for user input.  I have an editable DITL where the user types in a name and
>then clicks the OK button.  Non-TCL programs can use the GetDItem and GetIText
>functions to access what the user typed in.  I'm having a bear of a time trying
>to figure out how to get that string from the TCL-created dialog box, because
>TCL creates a dialog as panes in a window?
>
>Someone suggested using FindViewByID, but I'm not sure how that's going to
>help.
>

Yes it helps!

for example you can write:

class CYourDLOGDialog : CDLOGDialog {
public:
    CEditText   *itsEditText ;

    void    IYourDLOGDialog(void) ;
}

CYourDLOGDialog::IYourDLOGDialog()
{
    itsEditText = (CEditText *) FindViewByID(THE_ID_OF_YOUR_EDIT_TEXT) ;
}

Then once you have you EditText pane, you can use the corresponding method
to set or get text.

- --
Francois Menneteau ()   __|||||__   () "... I had their lives in my hands
================== ()    /O   O\    () their fate their fortune in my visions
[e-mail]       ()    - .|. -    () No one believed in my true prophecy
================== ()     \=^=/     () And now it's too late."  (Iron Maiden)

---------------------------

From: [e-mail] (Stuart Burden)
Subject: tickle (was Re: Porting tcsh to MacOS )
Date: 19 Mar 92 03:43:22 GMT
Organization: Avalon, beyond the Mists

In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Ed Lai) writes:
  | If you want to have a shell, another program to consider is Tickle, which so
  | happend is also based on Tcl. You can write XTCL (Tickle's XCMD counterpart)
  | to extend it to do what you want. XTCL has code resource so you can also do
  | it with PASCAL. You can get Tickle, which is free by ftp from ftp.msen.com
  | in the directory pub/vendor/ice.

Speaking of tickle.. has anyone written any neat/useful XTCL's yet
that can be shared?

I have several scripts (I've posted one already).. but haven't seen
any XTCL's except those that Tim provided with the release.

Cheers.

Stu.

- --
[e-mail]
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Eric W. Sink)
Date: 19 Mar 92 14:52:05 GMT
Organization: University of Illinois at Urbana-Champaign

In <[e-mail]> [e-mail] (Stuart Burden) writes:

>Speaking of tickle.. has anyone written any neat/useful XTCL's yet
>that can be shared?

>I have several scripts (I've posted one already).. but haven't seen
>any XTCL's except those that Tim provided with the release.

I'll probably be writing some, as soon as I figure out how to write
them using THINK C instead of MPW.

Speaking of tickle.. has anyone else noticed that tickle does most of
what FilterTop is supposed to be ?

- --
Eric W. Sink,  Spatial Analysis and Systems Team
USACERL, P.O. Box 9005, Champaign, IL 61826-9005
1-800-USA-CERL x449,   [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Ed Lai)
Date: 20 Mar 92 21:13:36 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (Stuart Burden) writes:
>
>Speaking of tickle.. has anyone written any neat/useful XTCL's yet
>that can be shared?
>
>I have several scripts (I've posted one already).. but haven't seen
>any XTCL's except those that Tim provided with the release.
>

It should be fairly easy to do a DoXCMD/DoXFCN XTCL, that would making
writing a lot of XTCL unnecessary. And writing a DoFKEY XTCL would require
almost no effort at all.


/* Disclaimer: All statments and opinions expressed are my own */
/* Edmund K. Lai                                               */
/* Apple Computer, MS37-UP                                     */
/* 20525 Mariani Ave,                                          */
/* Cupertino, CA 95014                                         */
/* [phone]                                               */
zW@h9cOi


---------------------------

From: [e-mail]
Subject: PBOpen crashes on "." names
Organization: Pomona College
Date: 19 Mar 92 16:17:11 PST

    Why is it that the Finder in System 7 allows you to prefix a filename
with the "." period character?  That character in the first position is
reserved for driver names as far as I've been told.  Now, perhaps most of the
system is intelligent enought o determine the difference between a driver named
.something and a file, but it does not appear to be that way in most cases.  If
you try to do a PBOpen ASYNC on a file name like ".login" (a common UNIX
filename) in the Mac file system, some Macs will crash immediately and others
will crash soon thereafter from corruption.
    Is there a safe way to open files named this way?  If not, why does the
Finder allow it?

______________________________________________
Frank Price  | [e-mail]


+++++++++++++++++++++++++++

From: [e-mail] (Pete Resnick)
Date: 20 Mar 92 15:49:44 GMT
Organization: University of Illinois at Urbana

[e-mail] writes:

>    Is there a safe way to open files named this way?  If not, why does the
>Finder allow it?

Yes. Under System 7, use PBOpenDF instead. This will not work under System
6 or less.

pr
- --
Pete Resnick             (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

---------------------------

From: [e-mail] (Brad Morris)
Subject: Offscreen Bitmap Problem SOLVED!
Date: 20 Mar 92 14:59:17 GMT
Organization: University of Chicago Computing Organizations

I posted about a month ago saying that I was having trouble using
code in Tech Note #120 to create offscreen bitmaps.  I have solved
my problem but don't really understand why.  Details:

The symptoms were that using the apple offscreen bitmap code
(creating the offscreen world from scrach, not using gWorlds)
everything worked fine on 32 Bit QD machines, but not on non
32 Bit QD machines.  The bitmaps appeared as they would in two
color mode when tried on non 32 Bit QD machines.

After fiddling around a bit, I decided that it might be because
I was converting a pallette to a CLUT to pass to the offscreen
bitmap creation code.  Copying the pallette into a CLUT did no
good.  But when I rearraged the CLUT, putting black last instead
of second of sixteen, things worked fine.  The original reason
I put black second in the pallette is that ResEdit says to do so.

So I think that non 32 Bit QD gave up searching the CLUT when it
got to black, but 32 Bit QD searches the entire CLUT.  Does this
make sense?

If you have any thoughts or comments, please reply via email.
I will post a summary if there is interest.

Brad Morris
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 20 Mar 92 19:15:20 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.edu> [e-mail] (Brad Morris) writes:

   After fiddling around a bit, I decided that it might be because
   I was converting a pallette to a CLUT to pass to the offscreen
   bitmap creation code.  Copying the pallette into a CLUT did no
   good.  But when I rearraged the CLUT, putting black last instead
   of second of sixteen, things worked fine.  The original reason
   I put black second in the pallette is that ResEdit says to do so.

If you read Inside Mac V, you'll see why it says so.

When using a palette; colors are allocated in order as long as there
are any free left. Black & white are very important, ergo they come
first in the palette.

However, Inside Mac ALSO says that the first & last entries in a CLUT
should be white & black respectively. This is because QuickDraw is
written that way (which makes sense; extending "0" and "1" to
"00000000" and "11111111" is simpler than to "10010111" and "00110100")

Hope this helps some,

- --
This signature is placed into the Public Domain by Jon W{tte ([e-mail])
                     - The worlds only romantic cynic -

---------------------------

From: [e-mail] (Dennis Y. K. Wong)
Subject: Questions on THINK Pascal
Date: 20 Mar 92 23:45:15 GMT
Organization: Elect & Comp Engineering, U of Manitoba, Winnipeg, Manitoba,Canada

Does anybody out there know the difference of using
Units & Libraries in a project on THINK Pascal? I mean
the difference on the execution time of a program. I try
to look up from the manual but it does not mention anything
about that.

I am programming a large program managing complex numbers.
I define all related functions & procedures in a unit.
I've already tried to build that unit as library. And the
excution time is significantly fast by using library. But I
wonder why there is a big difference. According to the manual,
the difference between Units & Libraries are the compilation
time. Is there any more explanations?

Another question: How to program to animate the cursor?
I know that I have to create 'acur' & 'CURS' resources but
I don't know how to animate it.

Last question: How to play a sound resource on Pascal program?

I don't have the Inside Macintosh, could anybody provide me
the answer?

Thanks.

+++++++++++++++++++++++++++

From: [e-mail] (Rich Siegel)
Date: 21 Mar 92 04:56:56 GMT
Organization: Symantec Language Products Group

In article <[e-mail]> [e-mail] (Dennis Y. K. Wong) writes:
>
>I am programming a large program managing complex numbers.
>I define all related functions & procedures in a unit.
>I've already tried to build that unit as library. And the
>excution time is significantly fast by using library. But I
>wonder why there is a big difference. According to the manual,
>the difference between Units & Libraries are the compilation
>time. Is there any more explanations?

    If the unit in your project has the "D" option turned on (for
debugging), then code in that unit will run slower than normal, because
of the overhead of the debugging support. Debugging code is *not*
generated for code compiled into libraries or built applications, or
if the "D" option is turned off for that particular file.

R.



- --
- -----------------------------------------------------------------------
Rich Siegel                              Internet: [e-mail]
Senior Software Engineer                 Applelink: SIEGEL
Symantec Languages Group

---------------------------

End of C.S.M.P. Digest
**********************